Video servers, including networked video servers, are known in the art. At the transmitting end, video servers include a library of multimedia (e.g. video and audio) sources, which typically consists of movies or other entertainment, often referred to as "titles". The video and audio that make up a title are stored as "bit streams" or simply referred to as "streams" on the video server. Video servers permit one or more users to select one or more of the movies for viewing. An admission arbitrator unit is provided to limit the number of users allowed to use the video server at any given time, to prevent overloading the network or disk storage subsystem. Such overload could cause movies to run too slowly or to move forward (or backward) in a jerky manner.
The video server includes magnetic storage hard disk drives on which recorded blocks from the video titles are magnetically stored. Titles might be any length, from a 30-second commercial to a two hour feature movie. For VHS-quality video streams, the delivery rate is typically 1.5 to 2 Mbit/second for MPEG-1 encoding; 4 Mbit/second for MPEG-2 encoding. Full resolution (CCR-601) video is typically recorded at a higher rate (4 to 8 Mbit/second); HDTV Grand Alliance systems allow rates of 10 to 45 Mbit/second. Thus, one MPEG-1 or MPEG-2 movie may require 1 GB to 8 GB of storage media, with a typical two-hour, VHS-quality movie consuming about 1.8 GB of disk space.
To sustain the throughput that is required for the timely delivery of video streams, you cannot store the bit stream for a single movie in a single hard disk unit, because a typical single hard disk drive can only output data at the rate of a few MBytes/second. To circumvent this bottleneck, it is common to store blocks of the movie (e.g., perhaps 0.5 second sequences) in multiple hard disk units. These blocks are then read out to a buffer, and communicated over the network. As these blocks are sent over the network, new blocks from the movie are read out from a set of hard disk units, hereinafter referred to as a disk array. At the receiving end, the blocks are decoded for user viewing on a video monitor, television receiver or the like.
The server delivers bit streams from the array of disks at a constant bit rate. The video server must assure that once a stream request is accepted, the stream is delivered at the specified constant bit rate until the stream ends or the server is told to stop.
Delivered video streams are independent in that they can each be stopped and started independently. Furthermore, these delivered bit streams may each contain different content (i.e. each being a different movie) or a plurality of delivered streams can be from the same content stream, such as a plurality of video streams containing video data from the same movie. Furthermore, the video streams from the same content need not be synchronized so that more than one viewer can be watching the same movie simultaneously, although one user started the movie at a different time from the other.
There are two general models used for video server systems. One is a so-called "pull" model, in which receiving devices request information from the video server, which then responds to these requests. In such "pull" type systems, there are inherently present controls to ensure that data is received on time and in a proper sequence even in the event of bit errors, since the receiving system is in essence in control of the video server and can re-request information or hold a request until a previous request has been properly received.
The other model for video servers is the "push" model, in which the video server receives an initial instruction to start a video stream, and thenceforth the video server "pushes" the video stream out at a constant bit rate with no dynamic flow control or error recovery protocol. In this "push" model of stream delivery, the server delivers video streams from the array of disks at a constant bit rate. The video server's requesting client can assume that once a stream request is accepted, the stream is delivered at the specified constant bit rate until the stream ends or the server is told to stop.
Video data, such as MPEG-1 and MPEG-2 encoded data, has time-critical properties that impose special requirements for real-time delivery of the data over a digital network from a server to one or more clients that decode the data. One reason for this requirement is that the greater expense of resources resides in servers rather than in receiving devices. For this reason, there is very little buffering available on decoders. (The amount of buffering is typically measured in milliseconds.) When a user requests the playing of a title, the server must ensure that almost every bit of the data arrives at the decoder (for example, a set-top box) at the time at which it was intended. Failure to meet such time-constraints can render the data useless.
Persistent or periodic failure to meet these time-critical requirements for video delivery manifests itself as "drift" and "jitter". Drift is a persistent trend in one direction such as when a server is continually late by a few milliseconds over time. Drift can render a title unintelligible. Jitter is a temporary overrunning or underrunning of an output device that might manifest itself, for example, in choppy movement in the display of a title. Drift and jitter must be constrained within guaranteed limits to ensure proper delivery of multimedia streams.
Information pertaining to the structure of MPEG data streams and the specific timing requirements are known and are provided, for example, in ISO draft international standard ISO/IEC DIS 13818-1, NXD, International organization for Standardization, 1994. In MPEG-1 and MPEG-2 video streams, the time constraints of a video stream are identified by a time stamp header contained in the encoded bit stream. This time stamp header is known as a Program TimeStamp (PTS) and is calculated with respect to a reference timebase known as the Program Clock Reference (PCR) or System Clock Reference (SCR). The time differences between any two continuous PCR time stamps must exactly reflect the time required to play out the number of bytes between the start of the two PCRs at the bit rate specified in the bit stream.
In the prior art, video data delivery at a constant bit rate is achieved by scheduling the video data delivery based on the underlying network clock, which provides timing for the bits transmitted on the network. Such an approach has the limitation that the delivered data rate is constrained to the granularities supported by network clock, and may make impossible the delivery of simultaneous video streams at arbitrary bit rates. Furthermore, the server design becomes dependent on the characteristics of the particular network output device and requires modification for each type of output device over which it must send data.
Compressed, motion video data files contain information in the form of a continuous stream of time-critical data. This stream contains pieces of system information (SI) at various positions within the video stream that define the time-critical property of the video stream. For example, for digital video that has been encoded using a MPEG-2 Transport Stream compression encoder, the SI information is reflected in the Program Clock Reference (PCR) in the system header. Typically, when these video data streams are stored on disk in a video server, the server uses the SI information that is embedded in the video data stream to schedule the transmission of the data at the appropriate time. The "at various positions" method of looking up the SI information for scheduling video data delivery typically results in a high CPU utilization on the server when there are a large number of video streams being transmitted simultaneously, thereby limiting severely the maximum performance of the server (in terms of number of simultaneous video streams that can be transmitted).